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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The smart card, tamper resistant device, has a primary role of storing credentials and performing sensitive cryptographic 
computations, it also provides portability of the user credentials. The smart card is rarely a stand-alone device; it usually 
interacts with a terminal. Sensitive applications are often split between a smart card and a terminal with sensitive data 
exchanged between the two. Therefore, the need to establish a secure channel between a UICC and a terminal that may 
host the UICC or be connected to the device hosting the UICC via a local interface has been identified by different 
standardization groups in order to protect the communication between the UICC and the terminal. 

This document describes key establishment between a UICC and a terminal. 
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Scope 



The present document describes the security features and mechanisms to provision a shared key between a UICC and a 
terminal that may host the UICC or be connected to the device hosting the UICC via a local interface. Candidate 
applications to use this key establishment mechanism include but are not restricted to secure channel between a UICC 
and a terminal ETSI TS 102 484 [8]. 

The scope of this specification includes an architecture overview and the detailed procedure how to establish the shared 
key between the UICC and the terminal. 
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The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
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• For a specific reference, subsequent revisions do not apply. 
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Release as the present document. 
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[9] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 
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[16] 3GPP TS 29.109: "Generic Authentication Architecture (GAA); Zh and Zn Interfaces based on the 

Diameter protocol; Stage 3". 



ETSI 



3GPP TS 33.1 1 version 7.2.0 Release 7 6 ETSI TS 1 33 1 1 V7.2.0 (2007-06) 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

NAF Key Center: Dedicated NAF in charge of performing the key establishment between a UlCC and a Terminal. 

UICC Hosting Device: The entity, which is physically connected to the UlCC. The UlCC Hosting Device may be the 
MT or the ME. 

Terminal: For the purposes of the present document, the term Terminal denotes a trusted device that can establish a 
shared key with a UlCC. The Terminal is a generic term aiming to address either the scenario where it is part of the 
UlCC Hosting Device or the scenario where it is a physically separated component (e.g. PNE as defined in 
TS 22.259 [4]). 

Remote Terminal: A Terminal that is physically separated from the UlCC Hosting Device. 

NOTE: The definition of trusted devices is out of the scope of the specification. It is assumed that the home 
network can decide whether a terminal is trusted or not. 

Editor's note: Some examples of trusted devices may be included. 

ICCID: ICCID is the identifier of the smart card. ICCID is defined in ITU standard and is encoded as a 10 octet string. 

Terminal_appli_ID: It identifies an application in a Terminal. Terminal_appli_lD is an octet string of maximum 
32 octets. If an application has an identifier of longer than 32 octets, this should be hashed using SHA 256 [10] into a 
string of length 32 octets which will be used as Terminal_appli_lD. 

TerminalJD: It identifies uniquely the Terminal and is 10 octets. The Terminal_lD of a ME is the IMEl and shall be 
encoded using BCD coding as defined in clause 10.5.1.4 of TS 24.008 [9]. 

NOTE: In case that the Terminal is not a ME the definition of the type of Terminal_IDs is out of the scope of the 
specification. 

UICC_appli_ID: It uniquely identifies an application in the UlCC. The UlCC_appli_lD is an octet string of maximum 
16 octets. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 
II Concatenation 
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3.3 



Abbreviations 



For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

B-TID Bootstrapping Transaction Identifier 

BSF Bootstrapping Server Function 

GBA Generic Bootstrapping Architecture 

GBA_ME ME-based GBA 

GBA_U GBA with UlCC-based enhancements 

ICCID Integrated Circuit Card Identification 

KDF Key Derivation Function 

Ks_ext_NAF Derived key in GBA_U 

Ks_int_NAF Derived key in GBA_U, which remains on UICC 

Ks_local Derived key, which is shared between a Terminal and a UICC 

NAF Network Application Function 

MAC Message Authentication Code 

PNE Personal Network Element 

SLF Subscriber Locator Function 

USS User Security Setting 



Key Establishment between a UICC and a terminal 



4.1 



Reference model 



GBA_U (TS 33.220 [3]) is used to provision a shared key between a UICC and a Terminal (i.e. Ks_local). The GBA_U 
key Ks_int_NAF is used by the UICC and the NAF to derive Ks_local. The NAF securely delivers Ks_local to the 
Terminal through a TLS tunnel, which is established between the NAF and the Terminal. 

Figure 4.1 and figure 4.2 show a network model of the entities that utilize the bootstrapped secrets, and the reference 
points used between them. In figure 4. 1 the Terminal is part of the UICC Hosting Device whereas in figure 4.2 the 
Terminal is connected to the UICC Hosting Device via a local interface. 
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Figure 4.1 : High level reference mode (the Terminal is part of the UICC Hosting Device) 
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Figure 4.2: High level reference mode (the Remote Terminal is connected to the UICC Hosting 

Device) 

Editor's note: It has to be confirmed if the reference point Ua shown in figure 4.2 is the same as defined in 
TS 33.220 [3]. 

4.2 Network elements 
4.2.1 NAF Key Center 

The NAF Key Center is the NAF in charge of performing the Key Estabhshment between a UICC and a Terminal. 

4.3 Key establishment architecture and reference points 

4.3.1 Reference points 

This document is based on the architecture specified in TS 33.220 [3]. The Reference Points that are not explained in 
this section can be found in TS 33.220 [3] and TS 29.109 [16] (including GAA Service Type Code for this 
specification). 

4.3.2 Reference point Ub 

The reference point Ub is implemented between the UICC Hosting Device and the BSF as described in TS 33.220 [3]. 
The UICC Hosting Device runs the HTTP Digest AKA protocol with BSF. This allows the UICC and the BSF to 
generate the bootstrapping key Ks. 

4.3.3 Reference point Ua 

The reference point Ua is used to deliver Ks_local and the associated parameters to the Terminal. 
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4.4 General requirements and principles for key establishment 
between a UICC and a Terminal 

4.4.1 General requirements 

The following requirements and principles are applicable to the procedure for key establishment between a UICC and a 
Terminal: 

The Terminal and the UICC shall be able to establish a shared key; 

The Terminal shall be trusted; 

NOTE: The definition of trusted terminal is out of scope of the specification. The terminal may be compliant 
to requirements defined in TCG Mobile Phone specifications [14] or TR 33.905 [13] 
"Recommendations for Trusted Open Platforms". 

The shared key to establish between the UICC and the Terminal (i.e. Ks_local) shall not be exchanged 
unencrypted on the interface between the UICC and the Terminal; 

The Terminal and the network shall be able to authenticate each other; 

The server implementing the key establishment function (i.e. the NAF Key Center) needs to be trusted by the 
home operator to handle the authentication parameters and the shared key; 

The home network shall be able to control whether this Terminal is authorized to establish a shared key with the 
UICC; 

The procedure for the key establishment between a UICC and a Terminal shall be access independent; 

To the extent possible, existing protocols and infrastructure should be reused; 

4.4.2 Requirements on the terminal 

The Terminal shall support certificate-based mutual authentication as defined in clause 5.5 of TS 33.222 [7] and 
IETF RFC 2246 [5] and IETF RFC 3546 [6]. Furthermore, the Terminal shall be equipped with a valid Client 
Certificate. 

4.4.3 Requirements on the UICC hosting device 

The UICC Hosting Device shall implement GBA_U as defined in TS 33.220 [3]. 

4.4.4 Requirements on the UICC 

The UICC shall implement GBA_U as defined in TS 33.220 [3]. 

The UICC shall be capable of deriving Ks_local from Ks_int_NAF. 

The NAFJD of the NAF Key Center shall be stored on the UICC. 

NOTE: The home operator can update the NAFJD of the NAF Key Center by means of OTA commands. 

It shall be possible that the UICC implements local policies to restrict the key establishment based on targeted UICC 
and Terminal applications (i.e. based on Terminal_appli_ID / UICC_appli_ID pair value), or based on Terminal_ID, or 
based on both targeted applications and Terminal_ID. 

4.4.5 Requirements on the NAF Key Center 

The NAF Key Center shall support certificate-based mutual authentication as defined in clause 5.5 of TS 33.222 [7] and 
IETF RFC 2246 [5] and IETF RFC 3546 [6]. 
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Editor's note: In addition to certificate-based authentication, another option might be defined 

The NAF Key Center shall be capable of determining whether a Terminal is trusted or not. 

The NAF Key Center shall implement GBA_U as defined in TS 33.220 [3]. 

The NAF Key Center dedicated to the Key Establishment Mechanism shall be located in the operator's Home Network. 

The NAF Key Center shall be capable of deriving Ks_local from Ks_int_NAF.lt shall be possible to configure the NAF 
Key Center to restrict the key establishment based on the targeted UICC and Terminal applications (i.e. based on 
Terminal_appli_lD / UICC_appli_lD pair value), or based on Terminal_lD and/or ICCID, or based on both targeted 
applications and device identifiers (Terminal_lD and/or ICClD). 

4.4.6 Requirements on Ksjocal key ancd associatecj parameters hancJIing 

The established key Ksjocal may be either a key shared between the UICC and the Terminal as monolithic devices or 
between a specific application on the UICC and a corresponding specific application on the Terminal. Ksjocal "per 
platform" refers to Ksjocal shared between the UICC and the Terminal as monolithic devices, whereas Ksjocal "per 
application" refers to Ksjocal shared between a specific application on the UICC and a specific application on the 
Terminal. 

Each Ksjocal is associated with a Key Lifetime for use in the terminal and a 16 octet Counter Limit value for use in the 
UICC. The NAF Key Center shall generate these values and deliver them to the terminal. The terminal shall forward the 
Counter Limit to the UICC when requesting the Ksjocal derivation. The Ksjocal derivation shall include the Counter 
Limit value from the NAF Key Center so that the UICC can be sure that the Counter Limit value was generated by the 
NAF Key Center and was not modified by the terminal. Details of how the UICC shall interpret the Counter Limit can 
be found in ETSI TS 102 484 [8]. 

The home operator may update the Ksjocal Counter Limit value by means of OTA commands. The description of the 
OTA mechanism is out of the scope of this TS. 

The Terminal shall delete Ks_local and the corresponding parameters (e.g.ICCID, Terminal_appU_ID, UICC_appli_ID) 
when at least one of the conditions below is met: 

1 - The key lifetime of Ksjocal expires; 

2- The Terminal detects that another UICC has been inserted. In order to make this condition possible, the Terminal 
needs to store in non-volatile memory the last inserted UlCC-identity to be able to compare that with the used 
UlCC-identity during the initialisation procedures; 

Ksjocal should not be deleted from the Terminal when the Terminal is powered down. If the Terminal does not delete 
Ksjocal at power down then Ksjocal together with the associated parameters (e.g. key lifetime and B-TID) shall be 
stored in trusted non-volatile memory. 

Editor's note: One way to have trusted non-volatile memory may be achieved by tamper-resistant hardware. 

4.5 Procedures 

4.5.1 Initiation of key establislnment between a UICC and a Terminal 

Before a Ksjocal-based application can start, the UICC and the Terminal first have to share the same key Ksjocal 
associated to the selected application. The Terminal shall check if it stores the key Ksjocal associated to the targeted 
application and if this key Ks_local is also available on the UICC. 
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1- The Terminal checks if it already stores a valid key Ksjocal required for the application communicating with 

the UICC. If a valid key Ks_local is not available on the Terminal then the Terminal initiates a Key 
Establishment procedure, else step 2 applies. 

2- The Terminal sends a request to the UICC to check that the required key Ksjocal is available on the UICC. 

The UICC reply indicates the Terminal if the required key Ks_local is available on the UICC. If the required 
key Ksjocal is not available on the UICC, the Terminal initiates a key establishment procedure, else a valid 
Ksjocal key is shared between the UICC and the Terminal. 

4.5.2 Key establishment procedure 

If a key establishment procedure is needed, it has to be performed as follows: 

1- The Terminal checks whether there is a valid Ks key in the UICC, by fetching the current B-TID and its 
corresponding lifetime from the UICC. If no valid key Ks is available in the UICC, the Terminal requests a 
GBA bootstrapping procedure run to derive a new Ks key in the UICC and the BSF. 

2- In order to check whether there is a valid Ks_int_NAF, the Terminal sends a request to the UICC to retrieve B- 
TID value associated to the NAF_ID of the NAP Key Center. In case that the Terminal does not know the 
NAF_ID of the NAF Key Center, the Terminal sends a request to the UICC to retrieve the NAF_ID of the 
NAF Key Center. 

3- The UICC returns the NAF_ID and associated B-TID to the Terminal. If there is no Ks_int_NAF available in 
the UICC, a GBA_U NAF Derivation procedure associated to the NAF Key Center is performed and then the 
UICC returns the NAF_ID and associated B-TID to the Terminal. 

4- The Terminal and the NAF Key Center establish a HTTPS tunnel with certificate based mutual authentication 
between the Terminal and the application server as defined in clause 5.5 of TS 33.222 [7]. 

NOTE 1 : One potential way to reach a trusted state is if the Terminal is compliant with the requirements defined in 
TCG (Trusted Computing Group) MPWG (Mobile Phone Working Group) Mobile Phone 
Specifications [14]. In PC -based TCG technology [15], HTTPS tunnel establishment can be bound to the 
trust status of the Terminal, through the attestations of relevant trusted engine of the Terminal. Similar 
Mobile functionality will be included in the TCG Mobile Phone specifications [14]. Thus, HTTPS tunnel 
establishment may in future be possible only if the Terminal is in a trusted state. 

Editor's note: In addition to certificate-based authentication, another option might be defined 

5- In order to retrieve Ks_local from the NAF Key Center, the Terminal sends a "service request" message to the 
NAF Key Center node in the mobile operator network. The message is sent within HTTPS tunnel. 

The request may contain the following payload: the identity (B-TID), the Terminal identifier (Terminal_ID), 
the smart card identifier (ICCID), the application identifier of UICC application (UICC_appli_ID) and the 
application identifier of the Terminal application (Terminal_appli_ID) requiring the establishment of key 
Ksjocal, and a variable value RANDx. 

NOTE 2: The variable value can be a random value or timestamp produced by the Terminal. 

In case that Ks_local has to be established per platform, the UICC_appli_ID and the Terminal_appli_ID octet 
strings equal to static ASCII-encoded string "platform". 

6- The NAF Key Center shall behave as follows: 

a) If the key establishment procedure is not allowed for the targeted applications or for the Terminal_ID/ICCID 
(e.g. if the Terminal ID is blocked (blacklisted)), according to the local administration then the NAF Key 
Center shall respond with appropriate error code and terminate the TLS connection with the Terminal. 

b) The NAF Key Center contacts the BSF and sends the identity (B-TID) and its own NAF_ID in a credential 
request. 
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7- The BSF derives Ks_int_NAF, Ks_ext_NAF and supplies to the NAF Key Center the requested keys 
Ks_int/ext_NAF keys, as well as the bootstrapping time and the key lifetime of Ks_int/ext_NAF keys. 

The BSF may also send requested USSs to NAF Key Center according to the BSF's policy 

8- The NAF Key Center shall behave as follows 

a) If the NAF Key Center has requested a USS, and the USS indicates to the NAF Key Center that the key 
establishment procedure is not allowed for the user, then the NAF Key Center shall respond with appropriate 
error code and terminate the TLS connection with the Terminal. 

b) The NAF Key Center generates a suitable 16 octet Counter Limit for use in the UICC. The NAF Key Center 
associates a key lifetime to the derived key Ksjocal for use in the Terminal. 

c) The NAF Key Center derives Ks_local from Ks_int_NAF. Ks_local is computed as Ks_local = KDF 
(Ks_int_NAF, B-TID, Terminal_ID, ICCID, Terminal_appli_ID, UICC_appli_ID, RANDx, Counter Limit), 
where KDF is the key derivation function as specified in Annex A. 

NOTE 3: If two applications on the UICC or on the Terminal have the same application identifier and RANDx is 
not renewed for each Ksjocal derivation, then Ksjocal will be the same for the two applications. 



£75/ 



3GPP TS 33.1 1 version 7.2.0 Release 7 1 3 ETSI TS 1 33 1 1 V7.2.0 (2007-06) 

9- The NAF Key Center sends within HTTPS tunnel a response message to the Terminal with the following 
payload: B-TID, Ks_local, Key Lifetime, and Counter Limit. 

10- The Terminal stores Ksjocal and associated parameters Key Lifetime, ICCID, Terminal_appli_ID, 
UICC_appli_ID 

1 1-The Terminal sends a command to perform Ks_local derivation on the UICC. The Terminal sends the NAP_ID 
corresponding to the NAF Key Center, the Terminal_ID, the Terminal_appli_ID, the UICC_appli_ID, RANDx 
and the Counter Limit value. The terminal also includes a MAC which is computed as MAC = HMAC-SHA- 
256(Ks_local, NAFJD II TerminalJD II ICCID II Term_appli_ID II UICC_appli_ID II RANDx II Counter 
Limit) truncated to 16 octets, where HMAC-SHA-256 with truncation is defined in NIST, 
FIPS PUB 1 80-2 [ 1 0] , IETF RFC 4634 [ 1 1 ] and IETF RFC 2 1 04 [ 1 2] . 

Terminal_appli_ID and UICC_appli_ID correspond to identifiers of applications that aim at sharing a key 
Ks_local. In case that Ksjocal has to be established per platform, the UICC_appli_ID and the 
Terminal_appli_ID octet strings are set equal to the static ASCII-encoded string "platform". 

12- The UICC retrieves the Ks_int_NAF and B-TID associated with the received NAFJD. The UICC may store a 
local policy to determine the associations between a Terminal_appli_ID and a UICC_appli_ID which are 
authorized. If the Terminal requested a Terminal_appli_ID/UICC_appli_ID association not authorized by the 
UICC policy, then the UICC stops the key establishment procedure and returns a "not authorized" error 
message. The local policy may also not authorize the key establishment procedure based on the Terminal_ID 
value. 

If the requested association is authorised, then the UICC derives Ks_local. Ksjocal is computed in the UICC 
as Ksjocal = KDF (Ks_int_NAF, B-TID, Terminal_ID, ICCID, Terminal_appli_ID, UICC_appli_ID, 
RANDx, Counter Limit), where KDF is the key derivation function specified in Annex A. 

The UICC verifies the MAC value received from the Terminal by computing MAC = HMAC-SHA- 
256(Ks_local, NAFJD II Terminal JD II ICCID II Term_appliJD II UICC_appliJD II RANDx II Counter 
Limit) truncated to 16 octets. If the MAC does not equal MAC, then the UICC terminates the key agreement 
procedure and returns a MAC verification failure message in response to the Ksjocal derivation request. 

13-If MAC-MAC then the UICC stores Ksjocal and associated parameters Terminal JD, Terminal_appliJD, 
UICC_appli JD and the Ksjocal Counter Limit. The UICC then sends a Ksjocal derivation response 
containing a MAC of the ASCII-encoded string "verification successful" using the key Ks_local and the MAC 
algorithm HMAC-SHA-256 [11] truncated to 16 octets IETF RFC 2104 [12]. 
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Figure 4-3: Key establishment procedure 



£75/ 



3GPP TS 33.1 1 version 7.2.0 Release 7 1 5 ETSI TS 1 33 1 1 V7.2.0 (2007-06) 

Annex A (normative): 

Key Derivation Function definition 

A.1 Ksjocal key derivation in key establishment 

The description of key derivation function KDF can be found in TS 33.220 [3]. The generic key derivation function and 
input parameter encoding in this document shall be implemented as defined in TS 33.220 [3]. 

A.2 Input parameters for Ksjocal key derivation 

In the key establishment between a UICC and a terminal, the input parameters for the key derivation function shall be 
the following: 

- FC = 0x01, 

- PO = B-TID, 

LO = length of B-TID is variable (not greater than 65535), 

PI = Terminal_ID, 

LI = length of Terminal ID is variable (not greater than 10 octets), 

- P2 = ICCID, 

L2 = length of ICCID is variable (not greater than 10 octets), 

P3 = Terminal_appli_ID, 

L3 = length of Terminal_appli_ID is variable (not greater than 32 octets), 

- P4 = UICC_appli_ID, 

L4 = length of UICC_appli_ID is variable (not greater than 16 octets), 

- P5 = RANDx, 

L5 = length of RANDx is variable (not greater than 16 octets). 

P6 = Counter Limit. 

L6 = length of Counter Limit is 16 octets. 

In case that derived key Ksjocal has to be established per platform, the UICC_appli_ID and the Terminal_appli_ID 
octet strings equal to static ASCII-encoded string "platform". 
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Annex B (normative): 

Key establishment UlCC-Terminal interface 

This annex describes the UICC-Terminal interface to be used to derive Ksjocal key in the UICC when there is the 
establishement of a shared key Ks_local between a UICC and a Terminal. 

B.1 Local Key Establishment: Key Derivation procedure 

This procedure is part of the key establishment to share Ksjocal key between a UICC and a Terminal. 

The Terminal has previously performed a GBA_U bootstrapping procedure and subsequent GBA_U NAF Derivation 
procedure, as described in TS 33.220 [3], with the NAF Key Center. The UICC stores the corresponding Ks_int_NAF 
and associated B-TID together with the NAF_ID of the NAF Key Center. 

The NAF_ID of the NAF Key Center is stored on the UICC. This value shall be accessible by the Terminal. 

The Terminal sends to the UICC the list of parameters described in the Terminal request for Ksjocal generation in 
clause 4.5.2. 

The UICC uses the NAF_ID to retrieve Ks_int_NAF associated to the NAF Key Center. The UICC derives Ksjocal 
from Ks_int_NAF as described in clause 4.5.2. 

After successful Ksjocal key derivation, the UICC stores Ksjocal and associated parameters as described in 
clause 4.5.2. 

UICC 

Terminal 

Local Key Establishment: Key Derivation mode 
Input parameters for Ksjocal generation 

•4 

Success/Failure 

► 

Figure B.I 

B.2 Local Key Establishment: Key Availability Check 
procedure 

This procedure takes place during the initiation of the key establishment procedure where the Terminal checks if the 
UICC already stores a valid key Ksjocal required for the application communicating with the UICC. 

The UICC has previously performed a Key Derivation procedure for the local key establishment. 

The Terminal sends either a Key Identifier of Ksjocal or no parameter. 

If the UICC received a Key Identifier of Ksjocal as input data then the UICC returns success/failure message, else the 
UICC returns the list of available Ksjocal key identifiers. 
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UICC 

Terminal 

Local Key Establishment: Key Availability Check mode 
Key Identifier / None 

< 

Success/Failure/List of available key identifiers 
► 



Figure B.2 
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